Recipes
Updating the Markdown
While you can provide initial Markdown inline, after the element is rendered, changing its contents will not cause it to re-render,
since its contents are now the parsed HTML (this is a disadvantage of this approach, compared to the Shadow DOM ones).
If you need to update its contents dynamically, use element.mdContent
.
You can also read that property to get access to the Markdown code that was last rendered, whether it came from the element's contents,
or fetched from a URL.
Note that setting mdContent
will override any remote URL provided via src
.
Minimizing FOUC
md-block adds a rendered
attribute to elements whose Markdown has been rendered.
This allows you to style unrendered content however you please, by using a md-block:not([rendered])
CSS selector.
- You could hide it entirely via
md-block:not([rendered]) { display: none }
- You could apply
white-space: pre-line
to it so that at least paragraphs are not all smushed together
- …or you could do something fancier.
I'd recommend you consider how it fails before deciding what to do. It's the Internet, 💩 happens.
Do you want your content to not be visible if a script doesn't load?
When loading remote content, there are two renders: First, any fallback content renders, then the remote content.
Because we often want to style the element differently until the remote content renders, the rendered
attribute has keyword values, depending on what happened:
fallback
when only fallback content has been rendered
remote
if remote content has been rendered
content
if element content has been rendered and there is no src
attribute present
property
if content has been rendered by setting this.mdContent
directly
Using different tag names
By default, md-block registers two custom elements: <md-block>
for block-level content and <md-span>
for inline content.
You can use different names, but since each class can only be associated with one tag name, you need to create your own subclass:
import {MarkdownBlock, MarkdownSpan, MarkdownElement} from "https://md-block.verou.me/md-block.js"
customElements.define("md-content", class MarkdownContent extends MarkdownBlock {});
Handling untrusted content
By default md-block does not santize the Markdown you provide, since in most use cases the content is trusted.
If you need to render untrusted content use the untrusted
attribute, which will dynamically load DOMPurify and use it.
This is not dynamic, you need to add it in your actual markup (or before the element is connected, if dynamically generated).
The reason is that it's unsafe to add it later: if the content has been already rendered once and treated as safe, it's pointless to sanitize it afterwards and re-render.
Important: Do not rely on the untrusted
attribute for inline Markdown! This is mainly useful for content linked via the src
attribute.
If there is potentially malicious code in the inline Markdown you are using, it will be picked up by the browser before md-block has the change to do anything about it.
Instead, use a regular <md-block>
element, and MarkdownElement.sanitize()
for the untrusted content.
Using different URLs for marked and DOMPurify
By default, md-block
dynamically loads marked and DOMPurify from a CDN. If you want to use different versions, there is a number of ways:
Probably the easiest is if you use the versions of these libraries that create a global, md-block will use that instead of loading them.
The URLs md-block uses to fetch these libraries reside on a separate URLs
export. So theoretically you could do something like this:
import {URLs as MdBlockURLS, MarkdownBlock, MarkdownSpan, MarkdownElement} from "./md-block.js";
MdBlockURLS.marked = "./marked.js";
MdBlockURLS.DOMPurify = "./purify.es.js";
But it's uncertain whether the new URLs will be picked up before the default ones load. In my tests that seems to work for DOMPurify but not marked.
These libraries are loaded when the element is connected, so you could add the <md-block>
elements dynamically to the document after you set the URLs, but that's a bit of a hassle.
Loading Prism dynamically
By default md-block
will use Prism if it's available, but won’t load it dynamically if it isn't.
You could tell it to load Prism dynamically, only if there are actual code elements, by providing a Prism URL:
import {URLs as MdBlockURLS, MarkdownBlock, MarkdownSpan, MarkdownElement} from "./md-block.js";
MdBlockURLS.Prism = "./prism.js";
MdBlockURLS.PrismCSS = "./prism.css";
<md-block>
inception
Did you know you can actualy use <md-block>
inside your Markdown and it works correctly?
For a cool example of this, check out the Stretchy docs
How to set different Markdown options/flavor?
Right now, this element uses GFM as a Markdown flavor and doesn’t expose a whole lot of options (besides hmin
and hlinks
).
That’s because I originally wrote it for my own needs, and that’s what I needed.
I’m not opposed to adding more customizability, if there are actual use cases that require it.
If you have such use cases, please open an issue.